安安～我是ChiYu～

昨天，我把一項通知重試需求拆成三個小週期，讓 Agent 每完成一段就取得測試回饋與回退座標，避免單一開發流程一次累積太多風險。

今天，我把開發線從一條增加到兩條：兩位 Agent 從相同 Commit 同時開工，再由 Integrator 合併與驗收，最後交給未參與實作的新 Agent 接手。誰先寫完，只是完整流程中的一小段；我還會把等待、整合、Review 與下一次修改一起算進來。

結果沒有出現「Owner 列得越細，團隊自然越快」這種整齊答案。功能責任＋局部自主的平行階段花了 649.189 秒；檔案責任＋HANDOFF_REQUEST 花了 708.632 秒。兩組 Cherry-pick 都沒有 Git Conflict，也都通過相同 Oracle，但嚴格檔案邊界預先暗示了 Reader 架構，最後讓查詢功能多出 Port、Snapshot、Adapter 與 DI。

接手實驗也呈現相同交換：直接 Projection 只需修改 3 個檔案；Reader 架構要同步 5 個位置。Reader 的角色比較明確，這次卻還沒有第二個查詢 Consumer 能支付這筆成本。

我最後接受功能責任＋局部自主，再加上接手 Agent 完成的 notificationKind 延伸。這不是因為檔案越少越好，而是目前任務可以自然切開，共同語意已有 Host Oracle 保護，直接 Projection 也仍有清楚修改路徑。

所以今天要回答的不是兩個 Agent 能不能同時產碼，而是從實作、等待、整合、Review 到接手，整個團隊是否真的變順。

Clean Code 如何把生產力從個人產碼，拉回團隊交付與接手

談到軟體工藝，生產力很容易被縮成「今天寫了多少行程式碼」。〈保持高生產力〉看的時間更長：Build、Test、Debug、Deploy 與修改結構時的阻力，會不會隨著每次交付持續增加？今天少花十分鐘寫完，卻讓下一次需求多花半天找規則，團隊沒有真的變快。

Clean Code 和團隊生產力的關係，也發生在這裡。名稱、責任、依賴與測試越清楚，下一位開發者越容易理解、驗證與修改；難讀又難測的程式碼，則會把今天省下的時間轉成未來的 Build、Debug、Review 與溝通成本。

〈團隊合作〉再往外問：成果能不能離開原作者，讓其他人補位？Pair Programming 通常由兩人共同處理同一項工作，持續交換實作、思考與 Review 角色；Mob Programming 則由整個團隊同時處理同一項工作。今天的 Agent 採平行開發，各自擁有獨立 Session，因此不能把這次實驗叫作 Pair 或 Mob，也不能拿結果替人類協作方式排名。

〈尊重其他程式設計師〉則讓接手成本更具體。清楚命名、可靠測試、合理文件、可理解 Commit，以及根據技術證據進行 Review，都在減少後來接手者猜測的時間。把一份只有原作者看得懂的成果交出去，即使功能正確，也等於把推理成本留給別人。

AI 可以提高局部產碼速度；Clean Code 追問的是，其他人或下一個 Agent 能不能理解、驗證並繼續改動這份成果。

Uncle Bob 的五段 Agent Pipeline，和本文的平行分工差在哪裡？

Uncle Bob 在近期訪談裡介紹一條五段 Agent Pipeline：Specifier 把需求整理成 Gherkin 與 QA Procedure；Coder 寫測試與 Production Code；Cleaner 清理結構並執行 CRAP 等檢查；Hardener 使用 Mutation Testing 補強測試；QA 最後從 UI 操作系統。

這條管線讓每一棒取得較聚焦的任務與 Context，下一個角色也會重新檢查上一棒成果；代價則是更多交接、等待與重複載入 Repository。他分享過一組個人案例：約五分鐘能產生初版的任務，走完整管線大約一小時，而人類可能需要半天。這是當時的個人實作經驗，不是可以直接套用到其他團隊的 Benchmark。

今天的設計不同。我讓兩個 Agent 從相同起點平行處理查詢與重試，再由 Integrator 合併，目的是觀察工作能否安全切開，以及整合與接手成本會不會吃掉平行化收益。五段 Pipeline 依角色串行，把品質檢查一層一層加上去；本文則依功能平行，最後共同驗收。

兩種方式沒有固定勝負。需要多層品質把關，而且每一棒輸入輸出清楚時，專責 Pipeline 很有吸引力；兩項功能能獨立開發、共享語意已有契約保護時，平行化才可能縮短牆鐘時間。若 Handoff 還在爭論欄位、狀態或副作用順序，多開 Agent 只會讓不確定性同時長大。

DORA 與 SPACE 提醒我：活動量只能用來診斷，不能直接叫作生產力

DORA 目前以五項 Software Delivery Performance 指標觀察軟體交付。Throughput 包含變更交付時間、部署頻率與失敗部署恢復時間；Instability 則觀察部署失敗及部署後返工的程度。它關心變更如何安全抵達 Production，不會把程式碼行數、Commit 數量或 Token 用量直接當成交付成果。

SPACE 從五個面向理解 Developer Productivity：Satisfaction and well-being、Performance、Activity、Communication and collaboration，以及 Efficiency and flow。Activity 只是其中一個面向，必須和成果、協作及工作流程一起判讀。

今天沒有部署到 Production，也沒有量測真實團隊成員的滿意度、干擾與人工 Review 時間，因此本文不構成完整的 DORA 或 SPACE 評估。我只借用它們的提醒，把下列資料當成交付流程的代理觀察：

我不把這些資料加總成一個生產力分數。每一項只回答它真正量到的問題。

GET 顯示「能重試」，POST 負責真的重試：兩項功能故意共享同一套業務語意

實驗起點沿用昨天接受的小週期版本：

• Commit：f58ab96bf3552ad584061eec70757a84848963b5
• Annotated Tag：day-27-small-cycles-improvement

讀者可以直接切到相同起點：

git clone https://github.com/eric861129/AI-CleanCode-API-Demo.git
cd AI-CleanCode-API-Demo
git switch --detach day-27-small-cycles-improvement

我沒有挑兩個完全無關的功能，因為那樣只能測到平行產碼。這次故意把「查詢通知狀態」與「重新啟動通知」拆給兩個 Agent：檔案看似可以分開，背後卻共享同一套「最新通知與是否允許重試」的規則，才能觀察兩份局部正確的結果整合後是否仍保持一致。

查詢 Agent：取得最新逾期通知狀態

第一項功能新增：

GET /api/work-items/{id}/overdue-notification

這個 API 讓維運或後台功能知道某個 Work Item 的最新通知目前是 Pending、Sent 還是 Exhausted：

• 找不到 Work Item：404 Not Found。
• Work Item 存在，但尚未建立通知意圖：204 No Content。
• 已有通知：200 OK，回傳通知 ID、狀態、嘗試次數、下次嘗試時間與 canRetry。
• 最新通知使用 CreatedAtUtc DESC, Id DESC 判定。
• 查詢使用 AsNoTracking，且不直接輸出 EF Entity。

重試 Agent：重新啟動已耗盡的通知

第二項功能沿用既有端點：

POST /api/work-items/{id}/overdue-notification/retry

昨天加入最大嘗試次數後，通知可能進入 Exhausted。今天要讓人工重送流程重新啟動同一筆 Outbox：

• Exhausted 改回 Pending。
• AttemptCount 歸零。
• 清除 Lease，NextAttemptAtUtc 改成現在。
• 保留通知 ID、Work Item ID、通知種類、建立時間與冪等鍵。
• 不立即呼叫 Provider，也不新增第二筆 Outbox。
• 重複 POST 仍回傳 202 Accepted。
• 最新通知已經 Sent 時維持 409 Conflict。

一個 Agent 寫 GET，另一個寫 POST，看起來很好拆。兩個功能仍共享四項不能各自決定的業務語意：

1. 以什麼排序找出最新通知。
2. Pending、Sent 與 Exhausted 各代表什麼。
3. Lease 尚未到期時，是否允許重新排定。
4. GET 回傳的 canRetry，是否和 POST 真正允許的操作一致。

如果 GET 回傳 canRetry: true，POST 卻因相同狀態回傳 409 Conflict，兩支 API 各自都可能有測試，組合起來仍然自相矛盾。這正好能檢查：兩份局部正確的 Agent 成果，整合後是不是還在說同一套業務規則。

兩種流程改的是一整組協作規則，這次不宣稱只有單一變因

為了避免前一次對話、個人 Memory 或額外工具替其中一組補充資訊，六個 Session 都固定使用 Codex GPT-5.6-SOL-HIGH，並停用個人 Plugin、Memory 與其他 Agent 功能。起始 Commit、功能需求與主流程最終驗收也保持相同。

第一組採「功能責任＋局部自主」：

可以修改完成任務所需的任何檔案。
另一位 Agent 會從相同 Commit 平行處理另一項功能。
不要替另一位 Agent 實作他的功能。

第二組採「檔案責任＋HANDOFF_REQUEST」。HANDOFF_REQUEST 是我在本系列 Prompt 中自訂的交接格式，不是 Codex 或 GitHub 的內建標準。當 Agent 發現需求超出責任範圍時，只回報目標檔案、必要修改與驗收理由，不自行跨越邊界：

你只能修改列出的責任範圍。
不得修改另一位 Agent 負責的 Scheduler、Controller、Entity 或 Tests。

若完成需求需要跨界修改，保留現有檔案不動，並回報：

HANDOFF_REQUEST
- target: <檔案>
- change: <必要修改>
- reason: <驗收理由>

這裡的 Ownership 指責任、可修改檔案與最終決策權的歸屬。第二組除了限制檔案，也加入禁止區域、跨界交接格式，以及預先列出的新檔案名稱。這整組限制可稱為 Workflow Policy Bundle，所以不能把實驗解讀成只差「有沒有檔案清單」的單一變因。

每種流程也只執行一次。這是一組固定條件下的案例比較，可以找出流程可能帶來的效果，不能證明所有 Repository 都會得到相同結果。

Prompt 裡的 Ownership 不等於 GitHub 的 CODEOWNERS。CODEOWNERS 依路徑指定 Reviewer；Branch Protection 替特定 Branch 設定 PR、Review 與 Status Check 等合併條件；Ruleset 則用一組規則管理 Branch 或 Tag 的建立、更新與合併。

這些工具可以安排 Review 路由與合併 Gate，無法替 Reviewer 判斷兩支 API 是否使用相同的業務語意。

flowchart TD
    B[相同 Baseline Commit]

    B --> A[功能責任＋局部自主]
    B --> O[檔案責任＋HANDOFF_REQUEST]

    A --> AQ[查詢 Agent]
    A --> AR[重試 Agent]
    AQ --> AI[整合與共同驗收]
    AR --> AI
    AI --> AH[全新 Agent 接手修改]

    O --> OQ[查詢 Agent]
    O --> OR[重試 Agent]
    OQ --> OI[整合與共同驗收]
    OR --> OI
    OI --> OH[全新 Agent 接手修改]

完整 Prompt、原始 Session、Run Metadata、Diff、Oracle 與驗證結果都保存在 Day 28 Public Evidence。

先寫六項獨立驗收，避免兩位 Agent 各自定義「正確」

這裡的 Host Oracle，是主流程在 Agent 動手前固定的獨立驗收測試。兩個 Agent 都會自行補測試，但各自寫出的測試可能剛好配合自己的實作；要公平比較，User 必須先把外部可觀察答案固定下來。

六項 Oracle 可以分成三組：

1. 查詢契約：找不到 Work Item 時回傳 404、尚無通知意圖時回傳 204，並依建立時間與 ID 找出真正最新的通知。
2. 共享語意：canRetry 必須同時正確反映通知狀態、Work Item 狀態與 Lease。
3. 重新啟動：Exhausted 要沿用原本 Outbox 並保留穩定欄位，最新通知為 Sent 時則維持 409。

基準版本的既有回歸測試保持綠燈；加入今天的 Oracle 後，有四項如預期轉紅。這個紅燈確認新增 GET 與 Exhausted 重啟行為確實尚未完成，也避免 Agent 用自己寫的測試定義自己的答案。

嚴格檔案邊界縮短了重試流程，預先命名 Reader 卻增加了查詢架構

先看四個實作 Session 的結果：

Fresh input tokens 是本次輸入總量扣除 Cached input 後的診斷值，可以觀察有多少未命中快取的內容再次進入模型 Context。它不能直接證明 Agent 的理解程度、程式碼品質或實際節省費用。

這次 Run 裡，重試 Agent 在檔案責任限制下，只需處理 Retry Scheduler 與對應 Contract Tests，不必探索 Controller、DTO 或查詢流程。相較局部自主版本，它少了 12 次 Command，完成時間也少約 189 秒。

查詢 Agent 的結果剛好相反。Ownership Prompt 事先列出兩個尚未存在、但允許建立的檔案：

• OverdueNotificationStatusReader.cs
• EfCoreOverdueNotificationStatusReader.cs

Agent 把檔名當成架構提示，建立 Reader Port、Use Case Snapshot、EF Adapter、DI 與 Boundary Test。新增資料轉換後，契約測試一開始沒有通過，Agent 修正 Mapping 才取得綠燈。

功能責任＋局部自主版本則將單一 HTTP 查詢留在既有 Controller，使用 AsNoTracking 與 DTO Projection；修改沒有跨入重試流程，也沒有增加架構層。

這個差異提醒我：Ownership 清單若列出尚未存在的抽象檔名，User 已經在替 Agent 暗示架構。只想分配責任時，寫「你負責通知狀態查詢，不得修改重送流程」會更接近真正意圖；等 Repository 已接受 Reader Port，再把既有路徑列進檔案清單。

這次平行執行中，嚴格檔案 Ownership 的總等待時間反而較長

兩個 Agent 平行執行時，這一階段的牆鐘時間由較慢的 Session 決定。一個 Agent 先完成並不會讓整組提早結束，Integrator 仍要等另一條開發線交付。

在這一次 Run 裡，檔案 Ownership 版慢約 59 秒。重試 Agent 少探索的收益，被查詢 Agent 提前建立 Reader 架構的成本抵銷。這只能描述各跑一次的兩組 Session；樣本不足以替多 Agent 協作方法排名。

單看時間仍然不夠。較少檔案可能代表結構剛好夠用，也可能只是把責任塞在同一處。下一步要把兩份 Commit 合在一起，再看 Reviewer 與接手者實際需要理解多少內容。

Git 能順利合併，不代表兩份候選的 Review 成本相同

Integrator 依相同順序 Cherry-pick 查詢與重試 Commit：

兩組 Cherry-pick 都在一秒左右完成，Git Conflict 也都是 0。Git 只檢查文字區塊能否合併，無法判斷 GET 與 POST 是否共享同一套「最新通知」與 canRetry 語意。

本文所說的 Review 面積，指 Reviewer 需要檢查的 Production 檔案、Diff 與語意同步點，並不代表真實人工 Review 分鐘數。檔案 Ownership 版多了 Reader Port、Snapshot、EF Adapter 與 DI 四個檔案，Production Code 也多 76 行；這些都是需要理解的結構成本。

完成整合後，兩份候選都通過相同的六項 Host Oracle，以及 Build、完整回歸測試、Format、Publish 與 Smoke。它們在已定義的外部行為上都合格，差異落在結構與後續修改路徑。

兩份候選都可合併，Review 仍找出架構暗示與 canRetry 漂移風險

Google Engineering Practices 強調 Code Review 應依據技術事實與資料，Comment 也要說明理由。依這項精神，我在本次實驗中把 Finding 分成 Required、Optional 與 Nit。

依這個標準，兩份候選都沒有 Required Finding；HTTP Contract、排序、Exhausted 原筆重啟、冪等鍵與副作用都符合 Oracle。Review 仍留下三項資訊：

1. 第一項流程警訊：檔案 Ownership Prompt 預先列出不存在的 Reader 檔名，限制範圍的同時也暗示了架構。
2. 第二項流程警訊：兩組都是零 Git Conflict，這個數字完全分不出語意整合與 Review 成本。
3. 一項 Optional 結構風險：GET Projection 與 Retry Scheduler 都知道 Overdue、Pending、Exhausted 與 Lease 條件。未來若只修改其中一邊，canRetry 可能和 POST 行為漂移。

我目前不把 GET 與 POST 共用的 canRetry 判斷抽成新的 Policy 類別。這是同一條規則第一次同時出現在查詢與命令流程，現有 Contract Tests 也還能保護它。以下任一情況出現時，才升級結構：

• canRetry 規則再次改變。
• 出現第二個查詢或命令 Consumer。
• GET 與 POST 的測試開始出現語意漂移。
• 同一段判斷需要被 Provider、背景排程或其他模組重用。

Clean Code 的 DRY 要處理知識重複。第一次看見風險就建立抽象，可能只是把兩段簡單判斷換成另一個同步點；先保存觸發條件，能讓下一次真實變更決定這項抽象值不值得建立。

用全新 Agent 模擬接手：直接 Projection 改三處，Reader 架構改五處

最後，我安排兩個全新的接手 Session，分別修改兩份整合候選。它們沒有參與前面的開發，只能讀 Repository Instruction、Git History、Diff、Tests 與現有程式碼。

兩邊收到相同的小型後續需求：

在 GET 的 200 OK 新增 notificationKind，值必須來自最新 Outbox；不可寫死 Overdue，也不能改變 POST retry。

直接 Projection 的版本有三個修改落點：

Response Contract
    ↓
Controller EF Projection
    ↓
Contract Test

Reader 架構則有五個修改落點：

EF Reader Projection
    ↓
Use Case Snapshot
    ↓
Controller Mapping
    ↓
Response Contract
    ↓
Contract Test

Reader、Snapshot 與 Adapter 這些角色名稱讓資料流更容易說明，接手 Agent 也找齊所有同步點。代價同樣很具體：新增一個欄位要修改五個檔案。在這次接手實驗裡，Reader 架構比直接 Projection 多花約 110 秒，Fresh input tokens 也多 28,213。這些數字描述本次修改路徑，不能直接推論所有分層架構都會增加相同比例成本。

這裡的 Clean Code 取捨很有意思。清楚角色能提高表達力，額外 Mapping 與同步點卻會提高修改成本。結構是否整潔，要看下一次變更能否留在合理範圍；多一層 Port 或多一個命名良好的類別，本身都不是答案。

如果相同查詢未來還要服務第二個 Use Case、Background Worker 或另一種 Delivery 方式，Reader Port／Adapter 才開始有重用與替換價值。目前只有一個 HTTP 查詢 Consumer，我還看不到足以支付這筆成本的第二個情境。

圖：產碼速度只是局部指標；真正的團隊生產力還要計入等待、交接、整合、Review 與下一位 Agent 的接手成本。

目前只有一個查詢使用者，我選擇功能責任＋局部自主

最終我接受功能責任＋局部自主流程，再加上接手 Agent 的 notificationKind 延伸：

• Commit：65e68e7977dec0284cd9450d1a82a0f38c448db0
• Annotated Tag：day-28-team-productivity
• 六項 Host Oracle 與完整回歸測試：全部通過。
• Release Build：0 warnings／0 errors。
• Format、Publish 與系列 Smoke：全部通過。

讀者可以切到接受版本：

git switch --detach day-28-team-productivity

我接受它的原因很具體：目前只有一個 HTTP 查詢 Consumer，直接 Projection 已經能清楚表達排序、DTO 與 canRetry，接手 Agent 也只需修改三個落點。此刻多建立 Port／Adapter 會增加同步成本，Repository 還沒有第二個使用情境支付這筆費用。等查詢出現第二個使用者、既有 Port 已經穩定，或多個 Agent 開始修改相同 Contract 與狀態流程時，我才會改用更嚴格的檔案 Ownership。

這個選擇不會把其他協作方式永久排除。我會依下列條件切換：

這次結果至少沒有支持「Owner 列得越細，團隊自然越快」這個推論。穩定邊界、高碰撞區域與強制 Review 路由，仍然是 Ownership 值得採用的情境。

CLEAN 如何決定多 Agent 的分工方式

C — Context-Aware Code 情境感知：分工前先看架構、共享規則與責任歸屬

同一份 Ownership 規則，放進不同 Repository 會得到不同結果。這個小型 API 只有一個查詢 Consumer，列出尚不存在的 Reader Port／Adapter，讓 Agent 提前建立結構；在已明確採用 Application Port 與 Persistence Adapter 的系統裡，相同清單可能正好守住既有邊界。

C — Context-Aware Code 情境感知 要 User 在分派 Agent 前確認四件事：Repository 目前採用什麼架構、任務共享哪些狀態與副作用語意、團隊如何分工，以及誰擔任最終 Integrator。這次預先命名 Reader 檔案，示範了與 Repository 現況不相稱的 Context 假設，如何增加 Agent 的理解與同步成本。

L — Localized Change 局部變更：限制每個 Agent 的責任，也限制兩條開發線之間的未決事項

L — Localized Change 局部變更 在多 Agent 情境裡管理兩種範圍：每位 Agent 負責什麼，以及整合前還剩多少共同決策沒有答案。

功能責任＋局部自主版本沒有檔案清單，兩項修改仍自然落在查詢與重試流程；檔案 Ownership 則讓重試 Agent 少探索其他區域。兩條開發線最後都必須共同回答 canRetry、最新通知排序與 Lease 語意，所以只數修改檔案，仍看不出整合是否真的局部。

L 在這裡要檢查的是：每份 Diff 能否獨立說明與驗證、跨界需求是否有明確交接、兩份局部結果整合後是否維持相同規則，以及下一位接手者要同步幾個落點。

把多 Agent 分工與接手條件整理成 Repository Policy

以下先用 AGENTS.md 格式保存局部自主、檔案 Ownership 與停止平行化的條件，尚未寫入 API Demo：

## Multi-Agent Collaboration Policy

- 平行開發前，先列出每項任務的責任、共同語意、可能修改的既有檔案與最終 Integrator。
- 任務自然分離且共同語意已有 Contract Tests 時，依功能分工；不得只為檔案 Ownership 建立尚未需要的 Port、Adapter 或架構層。
- 多項任務共享 Contract、Entity、狀態流程、Persistence 或副作用順序時，指定明確 Owner、介面、合併順序與共同 Oracle。
- 分配 Ownership 時，優先列出責任、禁止區域與既有檔案；只有 Repository 已接受該架構邊界時，才能預先列出尚未存在的 Port、Adapter 或抽象檔名。
- Agent 需要修改責任範圍外的檔案時，不得自行越界；回報 HANDOFF_REQUEST，包含目標檔案、必要修改與驗收理由。
- 介面與行為尚未穩定，或任務無法切出可獨立驗證的邊界時，停止平行化，改由共同設計或單一路徑先固定契約。
- CODEOWNERS 只負責 Review 路由；合併仍需 Branch Protection／Ruleset、共同測試與具備領域能力的 Reviewer。
- Review Comment 必須指出檔案或行為、證據、影響及 Required／Optional／Nit，不得用模型、作者或職級當作技術證據。
- 合併前執行共同 Oracle；合併後安排未參與實作的人或 Agent，依 Git History、Diff 與 Tests 完成一項小型接手演練。
- 評估結果至少分開記錄完成時間、等待、返工、整合失敗、Review 面積與接手結果；程式碼行數（LOC）、Commit、Token 與 Git Conflict 只能作為診斷訊號。

未來把可重用判斷抽成 Skill 會更適合。Repository 自己的模組名稱、測試指令、路徑與既有 Owner，仍要留在專案 Context。

兩條開發線不等於團隊變快

回到標題，AI 提高了同時產碼的能力，卻不會自動降低等待、整合、Review 與接手成本。這次兩組 Agent 都完成任務，也通過相同行為與工程 Gate，但嚴格檔案 Ownership 的平行階段反而較久，接手修改也需要同步更多位置。

我最後選擇功能責任＋局部自主，是因為兩項任務能自然切開，共同語意已有 Oracle，且目前只有一個 HTTP 查詢 Consumer。這是本次 Repository 的結構判斷，不是多 Agent 協作的永久排名。

真正的團隊生產力，要看成果離開原作者後是否仍能整合、驗證與繼續修改。兩種流程都只執行一次，也沒有 Production Deployment 或可靠的人工 Review 時間；文中的秒數、Token、Diff 與接手結果只能描述這個受控案例，不能外推成 DORA 改善，也不能宣稱人類團隊一定省下多少時間。

明天，我會接著處理另一個很容易被 AI 肯定語氣掩蓋的問題：當 Agent 給出看起來很精確的工期，工程師要怎麼把假設、未知、風險與信心誠實地說清楚。

參考資料

• DORA, Software delivery performance metrics。
• DORA, Finding balance in the era of tokenmaxxing。
• Microsoft Research, The SPACE of Developer Productivity。
• GitHub Docs, About code owners。
• GitHub Docs, About protected branches。
• Google Engineering Practices, The Standard of Code Review。
• Google Engineering Practices, How to write code review comments。
• Robert C. Martin／Matt Pocock，Uncle Bob on Software Fundamentals in the Age of AI：五段 Agent Pipeline，YouTube，2026-08-19。
• Robert C. Martin，SwarmForge，GitHub。
• Day 28 Public Evidence：Prompt、原始 Session、Diff、Oracle、Review 與接手結果。